perm filename RST.RAS[UP,DOC]1 blob
sn#625536 filedate 1981-11-20 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00011 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 .Rst= Rastor font file
C00006 00003 Vocabulary - needs work
C00007 00004 File Mark
C00009 00005 Preamble
C00014 00006 the preamble- discussion -needs update, the prev page is correct
C00018 00007 Directory and Rasters
C00022 00008 More on the directory and bit representation- needs update
C00027 00009 Still more...
C00030 00010 Naming font files
C00032 00011 Other Programs and Sources
C00033 ENDMK
C⊗;
.Rst= Rastor font file
This document describes the format of the Rst file as of August 1, 1981.
This is version 0. Please send comments and/or suggestions to RAS.
The Rst format was designed to be easy to use, compact and complete.
Growing from Les Earnest's FNT and Dave Fuchs' VNT formats, it was
developed by Imagen to be especially suited for use with Impress files.
Currently Rst files are used by the ImPrint-10 printer. Each is device
specific since each contains rasterized pictures. Printed, a font
specified by a given Rst file will vary in size depending on the
resolution of the printer; its quality may vary depending on the thickness
of a printed pixel (how well a printer focuses a dot).
MetaFont can create Rst files. At present there are no programs that
convert between Rst files and other formats. The program RdRst produces
an ascii textual description of an Rs file.
If any of these programs do not work with a command like ".r rstedf" the
program is not yet working.
INFORMAL DESCRIPTION
An Rst file contains a device dependent description of a font. The images
of characters are described by sequences of bit rasters that specify which
pixels in a bounding rectangle should be blackened.
In the beginning of the file there is a file mark, declaring the file to
be a Rst file. The Preamble is next, giving vital information about the
font, such as how many characters are in it, as well as non essential
information, such as who created the file. Next, the glyph directory
contains the size of each glyph and a pointer into the last section which
contains the raster data for each glyph.
Rst files are not sufficient for typesetting, which requires TFM files for
information about kerning and ligatures. However, Rst files contain
enough information to nicely print listings.
FORMAT DESCRIPTION
Rst files are comprised of 8-bit bytes. Often these are combined to form
multiple bytes fields for parameters. On Sail, 4 bytes are packed into
each 36-bit Sail word in the 32 high order (left) bits. The high byte is
the first byte in a word, the rightmost byte, the last. The first byte in
the file is numbered zero.
There are four parts to an Rst file, a font marker, the preamble, the
directory and the raster section. They occur in this same order in the
Rst file.
Vocabulary - needs work
glyph vs character vs symbol
pixel and bit
byte
two's complement
points
reference point
mag
designsize
space width
printing coordinates ↓→
rotation
advance directions and width
A FIX is an integer, equal to 2↑-20 points. There are 72.27 points per
inch. To convert a FIX integer, F, to a real number of points, R:
R← F / 2↑20;
File Mark
The first four bytes of an Rst file contain the ascii letters "Rast",
identifying the file type.
The next four bytes are currently unused.
In the eighth byte, the preamble begins.
The following are comments about the preamble...
[0][It sure is NOT the proper interline spacing!! For instance
the proper interline spacing for CMR10 is 12pt]
[1][how about in degrees/90, and only use one byte]
[3][come on--the codes for 34 and 35 should have the same decoding scheme.(Theydo!)
How about making it the same as byte 32: 0=above, 1=right, 2=down, 3=left;
32 is an informative number, corr to the degree rotation in MF,
28 and 29 are for printing, although one might want to print on a slant?
could make 0:3 mean abs dir, 4+(0:3) mean relative to degrees...
[4][in beginning, write #bytes in preamble, nothing at the end,
or, how about no marks at all! the fields are in fixed places, except for
the strings in the end. Hmmm, I guess you want to know how long it is if
you wanted to input it first, parse it later?
And these are for the rest of the file...
[5][wrong!]
Preamble
The preamble begins in the eighth byte of the Rst file with the number of
bytes containing the rest of the preamble, followed by the file's version
number. The file is version dependent. Version 0 has 18 fields of
information in at least 40 bytes. [4]
A string is represented as a sequence of 8-bit bytes. The first byte
contains the number of bytes in the rest of the string. Thus a string can
contain at most 255 characters, though most are only a few bytes long.
byt #bytes description of each preamble field
--------------------------------------------------------------------------
8 2 How many bytes in the rest of the preamble (at least 38);
10 1 The version number, latest version is zero.
11 3 pointer to the glyph directory (greater than or equal to 46).
14 2 Character number of the first glyph in the font, usually this is 0.
16 2 Character number of the last glyph in the font, usualy this is 127.
18 4 The magnification, in 1/1000's. For example, an unmagnified font will
have magnification 1000, a font that is twice as big as its designsize
will have magnification 2000 (0 mag should be interpreted as 1000).
22 4 The designsize (D) of the font, in FIXes. If the font is not magnified,
this will be the intended size of this font.
26 4 The interline spacing for the font, in FIXes. If this field is
zero, try designsize*1.2
30 4 Space width. The width of a good looking interword space, in fixes.
If this parameter is zero, try designsize/1.2
34 2 Rotation of the font in (ccw, positive) degrees. Normal fonts have
rotation 0; fonts to read while standing the page on its right edge
have rotation 270.[1]
36 1 Character advance direction relative to the font's rotation. This
tells where to place a "next character" on a "line of characters".
0=to the right, 1=below, 2=to the left, 3=upward. The English fonts
have character advance direction 0, Chinese:1, Hebrew 2.[3]
37 1 Line advance direction relative to the font's rotation. This tells
where to place a "next line of characters" on the page, relative to
the last line. 0=to the right, 1=below, 2=to the left, 3=upward.
The English fonts and Hebrew have line advance direction 1, Chinese:0.
38 4 A check identifier. This is used with metafont files to associate an Rst
file with a specific TFM file. This ensures that the TFM and Rst are
describing the same font. If this field is zero, no check is to be done.
(Note: One need not make the check, it is included to allow verification)
42 2 Resolution of the font in pixels/inch- 240 for the ImPrint-10.
44 var A font identifier string.
≥45 var A face-type encoding string.
≥46 var Output device string.
≥47 var Creator string. A verification program might check all the previous
fields for accuracy, but not this one.
the preamble- discussion -needs update, the prev page is correct
The first two fields must be correct for any Rst to be usable.
The next three fields are included to enable one to use the font to print
listings. Though the magnification can presumably be obtained from the
file name, it is included for verification and to allow a magnification of
greater precision than the file name might allow.
The magnification is needed in order to correctly interpret the widths
of the characters. The widths of the characters at their designsize are
stored in the directory. If the font is at twice magnification, the
characters are twice as big. The correct width of a character then is
its given width multiplied by the magnification.
The reason the magnification is not included in each character width is
to enable a printing program to substitute a font at one magnification
for another. If TEX says a VNT font file at mag 2.4 is called for, but
does not exist, but one at 2.5 exists, the latter can be used. The 2.5
characters will be printed, but the 2.4 widths can be printed by
multiplying by 2.4 instead of 2.5. This will make words with these
characters slightly cramped, but won't effect the spacing of the rest of
the document.
The designsize is the generic size of the font. It also tells the
distance between baselines and thus helps one use the font to make
listings. An N point font should have N/72 inches between baselines.
The width of a space determines the size of spaces and tabs. The purpose
of including these numbers is not to encourage low quality type-setting,
but to make it easier to print nicer listings with different fonts.[5]
The rest of the fields are present to encourage correctness. A
verification program can check that a font's file name corresponds to its
contents. A device dependent program assembling text can ensure the font
was made for it, or at least for a printer of its resolution. A user can
find out who made a font in case it needs to be improved.
Only the first four fields are mandatory.
Directory and Rasters
DIRECTORY:
The directory occupies 15 bytes times the number of glyphs in the font.
If FG is the first glyph in the font file, and DirPtr points to the first
byte of the directory, then the address of the directory entry, DE, for
character N is: DE ← DirPtr + ((N-FG)*15). Description of the contents of
the 4 words in an entry follows.
In a given directory entry, the bytes are:
#bytes info description
2 H: pixel height of raster picture
2 W: pixel width of raster picture
2 Y: pixel distance from top of raster array to reference point
2 X: same from left of raster array to glyph's reference point
4 FW: fix printing (nominal) width of character (signed quantity)
3 P: pointer to raster data
The first 4 bytes give the height and width in pixels (bits) of the rastor
array containing the glyph. The glyph is stored as a sequence of H rows,
each row being (W+7)%8 bytes long ("%" is truncating integer division).
A character has a reference point often near, or just left of, its center.
Y and X are the distances from the top left corner to this point in
pixels. Both of these numbers may be negative, in two's complement
representation. For the y-coordinate, positive is downward, for the x,
toward the right.
FW is the width of the character in FIXes. This is a signed quantity.
Remember to multiply this width times the magnification to get the true
physical width, in FIXes.
The final byte contains a pointer to the character's raster picture in the
data section.
Let BW be the width of the character in bytes (= (W+7)%8). All rows
start on byte boundaries and are packed to the left, so the last byte will
probably not be fully used.
(unless the width of the caracter is divisible by 32). The bits of the
picture are packed on the left, in the most significant bits.
So the entire glyph's picture takes up BW*H bytes.
(Remember at Sail all words in the file are stored in the high 32 bits,
even pointers and the (-1)s that delimit the preamble.)
More on the directory and bit representation- needs update
Again, the pixel height and width have no connection with the 'height' and
'width' that TEX thinks the character has (from the TFM file); rather,
they are the size of the smallest bounding box that fits around the black
pixels that comprise the character's raster representation. For example,
here is a letter "Q" from some Rst file:
0 ----**** ***----- -.......
1 ---***** ****---- -.......
2 --****-- -****--- -.......
3 -***---- ---***-- -.......
4 ****---- ---****- -.......
5 ***----- ----***- -.......
6 ***----- ----***- -.......
7 ***--*** **--***- -.......
8 ******** **-****- -.......
9 -*****-- ******-- -.......
10 --****-- -****--- -.......
11 ---***** ****---- -.......
12 --X-**** ***---** *.......
13 -------- ***--*** -.......
14 -------- -*****-- -.......
15 -------- --***--- -.......
76543210 76543210 76543210
Bit Number (high order bit is #7)
There are 4 words in the font marking, maybe 14 in the preamble, and 9*4
directory words before Q's, so if the first word of the file is numbered
zero, the directory for Q is in words 53-56.
directory entry, values of each byte are in octal:
53) 000 020 ← pixel height of rastor data (16)
000 021 ← pixel width of rastor data
54) 000 014 ← pixel y offset
000 002 ← pixel x offset
55) 000 125 142 131 ← number of fixes in printing width = 18 pixels
56) 000 001 420 ← where in the file the rastor data starts
(The rows and columns are numbered, and the reference point of the
character is marked with an X, but only the stars and dashes are actually
part of the character--stars represent black pixels, and dashes represent
white pixels. Periods represent zeros that are not part of the character,
but fill the bytes)
Note that the Pixel Width is just large enough to encompase the leftmost
and rightmost black pixels in the character. Likewise, the Pixel Height
is just large enough to encompass the topmost and bottommost black pixels.
So, this Q's Pixel Width is 17 and its Pixel Height is 16.
Here the offsets are the distances from the bounding box's top left corner
to the 'x' in the picture. The X-Offset is 2 and the Y-Offset is 12.
There are 26 characters in our font, but they need not be in order. If If
metafont made the letters from Z to A, then Q is the 10th letter. At an
average height of 15 or 16, the pointer to the bit raster may say its at
272, 4 for the font marker, maybe 14 for the preamble, 26*4 for the
directory plus 150 for the rasters.
Still more...
Bytes 8-11 in a glyph's directory entry contains the TFM
Width of the character. This is the width that TEX thinks the character
is when printed (exactly as in the .TFM file) in units of FIXes. The TFM
Width does not take into account the magnification at which the VNT file
was prepared and is completely independent of the glyph's pixel width.
Thus, if "Q" had a TFM width of 5620393 fixes, it would print at a width
of 5620393 fixes / (2↑20 fix/pts) / (72.27 pts/inch) * 240 pixel/inch=
17.8 pixels which would be rounded up to 18. This is a font about 5.4
points high.
If this font was, instead, 10.8 points high and thus at magnification .5
(one half), then the TFM width would have been 11367088, twice as much as
before, and only by multiplying it by the magnification (.5) would one get
the actual printing width.
Below is a the same letter Q with raster dimensions 16 pixels high by 17
pixels wide, showing the set bits in each byte. Note that the byte width
is 3 (17+7=24, 24%8=3) in order to accommodate the rightmost pixel in the
third row from the bottom.
600 00001111 11100000 00000000
601 00011111 11110000 00000000
602 00111100 01111000 00000000
603 01110000 00011100 00000000
604 11110000 00011110 00000000
605 11100000 00001110 00000000
606 11100000 00001110 00000000
607 11100111 11001110 00000000
608 11111111 11011110 00000000
609 01111100 11111100 00000000
610 00111100 01111000 00000000
611 00011111 11110000 00000000
612 00001111 11100011 10000000
613 00000000 11100111 00000000
614 00000000 01111110 00000000
615 00000000 00111000 00000000
76543210 76543210 76543210
Bit Number (high order bit is #7)
Naming font files
SAIL
At Sail, Rst files for the ImPress-10 reside on CAN,SYS, and have names
<name>.R##. Here the name is something like cmb10 or cmr13 and the ## is
a two digit number between 0 and 100 specifying 10 times the
magnification. For instance, "cmr10.v20[can,sys] is a a Rst file for the
ImPress-10 containing a cmr10 font at magnification 2.0. Check HELP
ImPrint to find out for what magnifications Rst files have been made.
Most likely DviImp will not substitute too freely, but moderate
magnifications will be well represented. Of course a user specified Rst
on a different directory can also be asked for in a DVI file. In this
case only the exact filename will be sought.
Other Programs and Sources
RstEdF produces an editable ascii file from an Rst file
EdFRst does the opposite- unfinished
Sail sources for these programs are in a spindle file RstSrc.spi[can,sys].
.READ SPINDLE for inforation about retrieval.